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REMARKS 
Status Summary 

Claims 21-25, 35, 38-40 and 45 currently stand rejected. In this Amendment, 
claims 22, 23, and 25 have been canceled or added. Therefore, upon entry of this 
amendment, claims 1-16, 21, 24, 26-28, and 35-45 will be pending. 

Claim Rejection - 35 U.S.C. § 103 

Claims 21-25, 35, 38-40 and 45 are rejected under 35 U.S.C. § 103(a) as 
being unpatentable over U.S. Patent No. 5,903,559 to Acharva et al. (hereinafter, 
" Acharva ") in view of U.S. Patent No. 6,801,500 to Chandran (hereinafter, 
" Chandran "). This rejection is respectfully traversed. 

Independent claim 21 recites a method for allocating bandwidth to a queue in 
a switch that includes receiving, from a user, a desired bandwidth in a standard 
bandwidth denomination provided by a switch. The desired bandwidth is 
automatically converted to at least one token bucket refresh rate by converting the 
desired bandwidth into a base bandwidth value and a residual bandwidth value, and 
computing a first token bucket refresh rate corresponding to the base bandwidth 
value and computing a second token bucket refresh rate corresponding to the 
residual bandwidth value. At least one token bucket that is associated with the 
switch is refreshed according to the base and residual bandwidth values. In the 
switch to be serviced, at least one queue is scheduled based on available tokens in 
the token bucket. 
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Independent claim 21 has been amended to recite that automatically 
converting the desired bandwidth includes converting the desired bandwidth into a 
base bandwidth value and a residual bandwidth value, wherein the base bandwidth 
value includes a bandwidth that is guaranteed to be provided every token bucket 
refresh interval by refreshing a first number of tokens every token bucket refresh 
interval and the residual bandwidth value includes a bandwidth that is spread over 
multiple token bucket refresh intervals by refreshing a second number of tokens 
every c token bucket refresh intervals, c being an integer greater than one, and 
wherein the base bandwidth value is greater than the residual bandwidth value . 
Support for this amendment can be found, for example, on page 7, lines 4-7, page 
12, lines 15-19, and page 15, lines 1-24 of the present specification. Claims 24 and 
38-40 depend from independent claim 21. Similar amendments have been made to 
claim 35. Claim 45 depends from independent claim 35. 

Thus, independent claims 21 and 35 respectively recite a method and a 
system for converting the bandwidth into a base bandwidth value and a residual 
bandwidth value that is less than the base bandwidth value, where the base 
bandwidth value includes a bandwidth that is guaranteed every token bucket refresh 
interval by refreshing tokens every refresh interval and a residual bandwidth value 
includes a bandwidth that is spread over multiple token bucket refresh intervals that 
is achieved by refreshing tokens every c intervals, where c is an integer greater than 
1. 
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For example, as described on pages 5-7 of the present specification, 
assuming that a refresh rate of 1 token per refresh interval corresponds to a 
bandwidth of 1 megabit per second, in order to achieve a user-specified (e.g., min, 
max, etc.) bandwidth of 1.1 megabits per second it would be necessary to provide 1.1 
tokens per refresh interval. However, because a token is an atomic entity that cannot 
be divided into fractions, the desired bandwidth of 1.1 megabits per second is divided 
into a base bandwidth value of 1 megabit per second and a residual value of 0.1 
megabits per second . (See pages 5-7 of the present specification). 

Next, the base bandwidth value is converted into a base token value 
corresponding to the number of tokens to be placed in the token bucket every token 
bucket refresh interval and the residual bandwidth value is converted into a residual 
token value corresponding to the number of tokens to be placed in the token bucket 
less than every token bucket refresh interval. A "base token refresh rate" may then 
be derived using the base token value and the token refresh rate and, similarly, a 
"residual token refresh rate" may be derived using the residual token value, the token 
refresh rate, and a distribution algorithm. Continuing the example above wherein the 
base bandwidth value equals 1 megabit per second and the residual bandwidth value 
equals 0.1 megabits per second, and further assuming, inter alia, that 1 token 
corresponds to 1 byte and a token refresh interval of 1 second, the base token 
refresh rate equals 1 token per second and the residual token refresh rate equals, on 
average, 1 token every 10 th second. (See Table 1 and page 16, line 6 - page 17, 
line 1 3 of the present specification). As described on pages 7 and 8 of the present 
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specification, an advantage of decomposing the desired bandwidth rate into a base 
bandwidth rate and a residual bandwidth rate is that incremental bandwidth can be 
automatically added to or subtracted from the bandwidth provided to a queue while 
avoiding burstiness and allowing the user to specify bandwidth in standard 
dominations, such as megabits per second, rather than token bucket refresh rates. 
(See page 7, line 11 - page 8, line 4 of the present specification). 

Page 2 of the Official Action concedes that Acharya fails to disclose, teach, or 
suggest "scheduling a switch queue according to at least one token bucket [refresh 
rate] associated with a base bandwidth [value] and a residual bandwidth [value]." 
(See page 2 of the Official Action). However, the Official Action asserts that 
Chandran discloses this feature. Applicants respectfully disagree. 

There is no disclosure, teaching, or suggestion in Chandran of converting a 
desired bandwidth value into a base bandwidth value and a residual bandwidth 
value, wherein the base bandwidth value includes a bandwidth that is guaranteed 
every token bucket refresh interval and a residual bandwidth value includes a 
bandwidth that is spread over multiple token bucket refresh intervals, as claimed in 
independent claims 21 and 35. In contrast, Chandran teaches that a minimum 
reserved rate and a maximum peak rate may be used for guaranteeing that the 
perceived rate as seen by the user is within a specified bandwidth range defined by 
the minimum and maximum rates (i.e., never falls below the reserved rate or exceeds 
the maximum peak rate). (See col. 1, lines 33-40 of Chandran ). The residual 
bandwidth value recited in claims 21 and 35 is different from the maximum peak rate 
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disclosed in Chandran because the residual bandwidth value in claims 21 and 35 is 

less than the base bandwidth value while the maximum peak rate in Chandran is 

greater than the desired bandwidth rate. For example, applying the subject matter 

recited in claims 21 and 35, a desired bandwidth rate of 1.1 megabits per second 

corresponds to a residual bandwidth rate of 0.1 megabits per second. In contrast, 

according to Chandran , it is respectfully submitted that the maximum bandwidth rate 

for a desired bandwidth rate of 1.1 megabits per second corresponds to any suitable 

bandwidth value that is greater than 1.1 megabits per second (e.g., 1.15 megabits 

per second). Thus, the maximum peak rate in Chandran will always be different from 

the residual bandwidth value in claims 21 and 35 for a particular desired bandwidth 

rate (e.g., 0.1 vs. 1.15 megabits per second). For this reason alone, it is respectfully 

submitted that the rejection of claims 21-25, 35, 38-40 and 45 should be withdrawn. 

Additionally, there is no disclosure, teaching, or suggestion in Chandran of a 

residual token value corresponding to the number of tokens to be placed in the token 

bucket less than every token bucket refresh interval (i.e., c>1 in claims 21 and 35). 

Instead, Chandran discloses that the reserved and peak token bucket refresh rates 

are equal to the network interface token bucket refresh rate and includes placing a 

number of tokens in a token bucket every refresh interval. For example, regarding 

token bucket refresh rates, Chandran states: 

The network interface could have a maximum capacity of N bits per second and 
each bit could be represented by one token. A spigot 109 would supply network 
interface token bucket 101 with N tokens per second. The N tokens may be 
added at one second intervals, or alternatively, spigot 109 may add a fraction of 
these N tokens at the same fraction of a second that has elapsed during an 
interval. (See col. 5, lines 54-56 of Chandran) . 
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Whenever the interface token bucket 101 is refreshed, the reserved and peak 
rate token buckets are also refreshed. (See col. 5, lines 54-56 of Chandran ). 

According to the above-quoted passages in Chandran , N tokens are added to 

network interface token bucket 101 (e.g., 800 tokens) every refresh interval (e.g., 

every second), a number less than N tokens are added to reserved token bucket 103 

(e.g., 200 tokens) every refresh interval, and a number less than N tokens are added 

to peak token bucket 105 (e.g., 300 tokens) every refresh interval. (See also, col. 5, 

lines 61-67 of Chandran ). In contrast, according to claims 21 and 35, residual token 

value corresponding to the number of tokens to be placed in the token bucket ]ess 

than every (i.e., c>1) token bucket refresh interval (e.g., 1 token every 10 th refresh 

interval). 

Accordingly, because Acharya and Chandran , even when combined, fail to 
disclosure, teach, or suggest converting a desired bandwidth value into a base 
bandwidth value and a residual bandwidth value, wherein the base bandwidth value 
includes a bandwidth that is guaranteed every token bucket refresh interval and a 
residual bandwidth value includes a bandwidth that is spread over multiple token 
bucket refresh intervals, it is respectfully submitted that the rejection of claims 21-25, 
35, 38-40 and 45 under 35 U.S.C. § 103 should be withdrawn. 
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Allowable Subject Matter 

Claims 1-16 are allowed. Claims 26-28, 36-37 and 41-44 were indicated as 
allowable if rewritten in independent form including all of the limitations of the base 
claim and any intervening claims. 

Claims 26, 36, and 41 have been rewritten in independent form. Claims 27, 
28, 37, and 42-44 each depend from one of claims 26, 36, and 41. Accordingly, 
claims 26-28, 36-37 and 41-44 should now be allowed. 

CONCLUSION 

In light of the above Amendments and Remarks, it is respectfully submitted 
that the present application is now in proper condition for allowance, and an early 
notice to such effect is earnestly solicited. 

If any small matter should remain outstanding after the Patent Examiner has 
had an opportunity to review the above Remarks, the Patent Examiner is respectfully 
requested to telephone the undersigned patent attorney in order to resolve these 
matters and avoid the issuance of another Official Action . 
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DEPOSIT ACCOUNT 
The Commissioner is hereby authorized to charge any deficiencies of payment 
or credit any overpayment associated with the filing of this correspondence to 
Deposit Account No. 50-0426 . 

Respectfully submitted, 
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